Bug Triage #525252: UnprefixedAttribute/PrefixedAttribute clunkiness

On Tue, Feb 3, 2009 at 11:25 PM, Alex Cruise <alex@cluonflux.com> wrote:

https://lampsvn.epfl.ch/trac/scala/ticket/739

I have no objection to Viktor's suggestions but I'm not confident that this kind of change can be made while preserving binary compatibility.  My inclination is to punt this one to 2.8.0.

There's no reason to have a shared superclass beyond MetaData.  It would make sense to have a MetaData companion object that has the variations on apply() to construct the various instances.
I've got no objection to making the various attributes case classes. 

-0xe1a

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

David Pollak wrote:
> There's no reason to have a shared superclass beyond MetaData. It
> would make sense to have a MetaData companion object that has the
> variations on apply() to construct the various instances.
The existing MetaData class strikes me as overly general considering the
simplicity of attributes. How about something like this?

- A new trait "Attribute", which both PrefixedAttribute and
UnprefixedAttribute will mix in (but which *does not* extend
Collection[MetaData]) or promise any other methods that are not
intuitively related to a single attribute)
- An Attribute object containing Viktor's suggested factory methods

And a few, less realistic suggestions:
- Move all the attribute-getting methods down to Elem from Node (why did
the W3C DOM do it this way?)
- Add another "attributes"-like method to Elem that returns
Seq[Attribute] instead of MetaData, and hopefully deprecate Node.attributes.

Thanks!

-0xe1a

On Wed, Feb 4, 2009 at 10:10 AM, Alex Cruise <alex@cluonflux.com> wrote:

David Pollak wrote:

There's no reason to have a shared superclass beyond MetaData.  It would make sense to have a MetaData companion object that has the variations on apply() to construct the various instances.

The existing MetaData class strikes me as overly general considering the simplicity of attributes.  How about something like this?

- A new trait "Attribute", which both PrefixedAttribute and UnprefixedAttribute will mix in (but which *does not* extend Collection[MetaData]) or promise any other methods that are not intuitively related to a single attribute)
- An Attribute object containing Viktor's suggested factory methods

Why?  What are the problems with the existing hierarchy?

Changing class hierarchies breaks binary compatibility.  Breaking binary compatibility is *VERY BAD* and should be done only if there's a compelling reason.
 

And a few, less realistic suggestions:
- Move all the attribute-getting methods down to Elem from Node (why did the W3C DOM do it this way?)
- Add another "attributes"-like method to Elem that returns Seq[Attribute] instead of MetaData, and hopefully deprecate Node.attributes.

Why?  Is stuff so very broken that we need to major-league rearchitect the whole XML library?
 

Thanks!

-0xe1a

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Changing class hierarchies breaks binary compatibility.  Breaking binary compatibility is *VERY BAD* and should be done only if there's a compelling reason.

I think binary incompatibility should be assumed between releases, especially 2.x releases. To do otherwise is to set yourself up for a nasty surprise.

--j

David Pollak wrote:
> On Wed, Feb 4, 2009 at 10:10 AM, Alex Cruise > wrote:
>
> The existing MetaData class strikes me as overly general
> considering the simplicity of attributes. How about something
> like this?
>
> - A new trait "Attribute", which both PrefixedAttribute and
> UnprefixedAttribute will mix in (but which *does not* extend
> Collection[MetaData]) or promise any other methods that are not
> intuitively related to a single attribute)
> - An Attribute object containing Viktor's suggested factory methods
>
>
> Why? What are the problems with the existing hierarchy?
#525252 is at least one vote that it could stand to be clearer and easier
to use.
> Changing class hierarchies breaks binary compatibility. Breaking
> binary compatibility is *VERY BAD* and should be done only if there's
> a compelling reason.
OK, clearly I've gotten off on the wrong foot by discussing design ideas
in a bug triage thread, and I apologize for that. I'm not proposing
breaking binary compatibility any time soon (if at all); at this point
I'm just trying to get a feel for the various ways the system could
evolve. If we end up with a long shopping list of changes that would be
"nice to have" but that would break backward compatibility, maybe a
scala.xml2 or scalax.xml would be in order.
>
> And a few, less realistic suggestions:
> - Move all the attribute-getting methods down to Elem from Node
> (why did the W3C DOM do it this way?)
> - Add another "attributes"-like method to Elem that returns
> Seq[Attribute] instead of MetaData, and hopefully deprecate
> Node.attributes.
>
>
> Why? Is stuff so very broken that we need to major-league rearchitect
> the whole XML library?
I *did* say "less realistic." :) I'll confine my Architecture Astronaut
EVAs to other threads. :)

Just out of curiosity, would it *necessarily* break binary compatibility
if two preexisting classes gained a new trait? I suppose that would
depend on whether there are any user-defined subclasses in the field.

-0xe1a

Alex Cruise wrote:
> https://lampsvn.epfl.ch/trac/scala/ticket/739
>
> I have no objection to Viktor's suggestions but I'm not confident that
> this kind of change can be made while preserving binary compatibility.
> My inclination is to punt this one to 2.8.0.

NB: I haven't thought this through; I'm just throwing up a new take on
this...

XML prefices are the sort of thing I really dislike having to write out
repeatedly. XML is verbose enough as it is without having to write a
bunch of characters and a colon twice for every node.

I'd like to define an implicit val, e.g.

implicit val namespace = Namespace("xsl")

and have it picked up by my node constructors and extractors[1] within
scope.

In Predef, we could define

implicit val namespace = DefaultNamespace

so that there's a sensible default namespace available.

I'm assuming we'll have some definitions like:

sealed trait XmlNamespace { def prefix : String }
case object DefaultNamespace { def prefix = "" }
case class Namespace(p : String) { def prefix = p+":" }

case class Elem(tag : String, atts : List[Attribute],
xs : List[Node])(implicit ns : XmlNamespace)

Obviously this would break a whole load of stuff, and I've also made no
attempt to think about namespace bindings.

Thoughts?

Cheers,
Jon

[1] While we're at it, it would be nice to have some Elem extractors
with fewer than half a dozen parameters...

Jon Pretty schrieb:
> sealed trait XmlNamespace { def prefix : String }

Shouldn't that be something along the lines of

sealed trait XmlNamespace {
def prefix: String
def uri: String
override def equals(that: Any) = {
if (that == null) false else
that match {
case ns:XmlNamespace => ns.uri == uri
case _ => false
}
}
override def hashCode() = uri.hashCode()
}

But that would at least be quite confusing...

- Florian

Hi Florian,

Florian Hars wrote:
> But that would at least be quite confusing...

This was why I didn't consider the URI namespace bindings... ;-)

But it is correct, and it would only be confusing in the relatively
unusual circumstance that you have different prefices for the same URI
binding.

On 05/02/2009, at 9:37 PM, Jon Pretty wrote:

> This was why I didn't consider the URI namespace bindings... ;-)
>
> But it is correct, and it would only be confusing in the relatively
> unusual circumstance that you have different prefices for the same URI
> binding.

I saw an example of different prefixes for the same URI on the top of
page 3 of https://wadl.dev.java.net/wadl20061109.pdf

It may not be as unusual as one might think...

Marc

Hi Marc,

Marc Boschma wrote:
> I saw an example of different prefixes for the same URI on the top of
> page 3 of https://wadl.dev.java.net/wadl20061109.pdf

But, given such an example, is equal to for any
good definition of equals? I presumed they were the same.

Jon

Jon Pretty wrote:
> NB: I haven't thought this through; I'm just throwing up a new take on
> this...
>
> XML prefices are the sort of thing I really dislike having to write out
> repeatedly. XML is verbose enough as it is without having to write a
> bunch of characters and a colon twice for every node.
>
> I'd like to define an implicit val, e.g.
>
> implicit val namespace = Namespace("xsl")
>
> and have it picked up by my node constructors and extractors[1] within
> scope.
>
> In Predef, we could define
>
> implicit val namespace = DefaultNamespace
>
> so that there's a sensible default namespace available.
>
Yeah, that lines up pretty well with what I was advocating way back in
http://www.nabble.com/Namespace-support-in-XML-patterns-td17562546.html
. We were talking about how to resolve namespaces in pattern matching
expressions, but you could, in theory, use the same implicit
NamespaceBinding concept for construction as well as extraction. It has
a nice symmetry with existing practice for case classes too.

For construction I don't see it as a huge win though, since there's
already a good shorthand if you want to prefixes (the following are
equivalent):

I suppose if you had multiple XML literals and/or matches in the same
method it might save you some aggravation to be able to omit the
prefixes and/or xmlns="..." declarations.

-0xe1a

Reading http://www.w3.org/TR/REC-xml-names/#dt-identical your
presumption seems valid, given the example.

6.1 & 6.2 are also interesting in the context of the discussion on an
implicit name space...

Marc

On 06/02/2009, at 12:36 PM, Jon Pretty wrote:

> Hi Marc,
>
> Marc Boschma wrote:
>> I saw an example of different prefixes for the same URI on the top of
>> page 3 of https://wadl.dev.java.net/wadl20061109.pdf
>
> But, given such an example, is equal to for any
> good definition of equals? I presumed they were the same.
>
> Jon
>

---------------------------------------+------------------------------------
Reporter: ViktorKlang | Owner: scala-xml_team
Type: enhancement | Status: closed
Priority: normal | Component: XML support
Version: Unreleased-2.8.x | Resolution: fixed
Keywords: scala. xml prefixes clunky |
---------------------------------------+------------------------------------
Changes (by extempore):

* status: new => closed
* version: => Unreleased-2.8.x
* resolution: => fixed

Comment:

As of r17609 I think you'll find higher unclunkiness levels. I did not
make them case classes or insert a class into the hierarchy; but I did
factor out their common interface into a trait called Attribute, create
extractors for that as well as the pre/unpre variants, and add a bunch of
convenience apply methods to the Attribute object.